Protocol analyzers are used as diagnostic and testing tools at various stages of the development, integration and maintenance of electronic computing devices. Typically, a protocol analyzer is designed for use with a particular electrical communication interface protocol, such as ATA, SCSI, Ethernet or Fibre Channel. In a typical use, the protocol analyzer is connected to the communication interface of the computing system being tested to record communication activity on the interface. The communication activity is captured and recorded in a dedicated trace buffer associated with the protocol analyzer, and then analyzed and/or presented to the user for the purpose of diagnosing, testing or maintaining the communication interface.
It will be apparent that the size of the trace buffer necessarily limits the amount of communication activity that can be recorded by the protocol analyzer. As the transfer speeds of communication interfaces among computing systems have increased, the need for larger or deeper trace buffers has also increased. In the early days of modern communication interfaces, trace buffers were relatively small (1K buffer) and were implemented as cache memories directly connected to a processor within the protocol analyzer, as shown, for example, in U.S. Pat. No. 4,949,252. When faster communication interfaces were developed, such as the Ethernet protocol, the size of the trace buffer increased (65K buffer) and filtering techniques were applied to minimize the amount of trace data which needed to be captured, as shown, for example, in U.S. Pat. No. 5,442,639.
While smaller size trace buffers were adequate to record communication activity for several minutes on moderate speed communication interfaces, such as the ATA or SCSI protocols, larger trace buffer depths are necessary to record communication activity for the same period of time on faster communication interfaces such as the Fibre Channel protocol. Examples of buffer sizes in existing Fibre Channel protocol analyzers include the Xyratex TP-5-100-PA+ Fibre Channel Protocol Analyzer Plus (3 MB to 24 MB), the Ancot FCA-5010 Fibre Channel Analyzer (524,000 event trace memory), and the Finisar GT-A Fibre Channel Protocol Analyzer (4 MB to 256 MB).
Managing the large amount of data generated by faster communication interfaces is difficult. Most of the faster communication interfaces today operate using packet data transfers in which packets of data, each with an associated header, are communicated among devices on the interface. One of the ways that the large amounts of data are managed in a packet data transfer system is to tightly integrate the communication buffer that receives the data packets from the communication interface with the processor. The communication buffer and the processor are typically interconnected by a common bus having a relatively large bandwidth in order to allow operations to be performed by the processor on the data packets within the communication buffer at the speeds that are required to keep up with the data transfer rate of the communication interface.
Different techniques have been proposed for improving the operational efficiency of buffers for packet data transfer communication interfaces in terms of the way in which the memory of the communication buffer is managed. One approach is to apply a filtering technique in order to reduce the amount of data that must be recorded to only those packets of data that are particularly of interest. Examples of various filtering techniques for packet data communication buffer management are shown in U.S. Pat. Nos. 5,648,965 and 5,761,424. Another technique is to capture only the header information associated with each data packet as shown, for example, in U.S. Pat. No. 5,526,283. Alternatively, it has been proposed to randomly select packets to be analyzed to minimize processor and buffer capacity requirements as shown, for example, in U.S. Pat. No. 5,315,580. The use of a serial state machine separate from the communication processor has also been proposed to handle communication packet processing as shown, for example, in U.S. Pat. No. 5,247,517.
Unfortunately, many of the techniques used in conventional data packet communication buffer management are not applicable to trace buffer management in a protocol analyzer because the trace buffer must be able to capture and retain significant volumes of data packets for purposes of subsequent analysis of an entire segment of a transfer; whereas communication buffers only temporarily hold data packets until they have been processed in a serial fashion by the device to which they have been sent.
In each of the existing Fibre Channel protocol analyzers, the trace buffer memory is physically located within the same chassis as the processor which operates the protocol analyzer, and, like conventional communication buffers, is connected to the processor by a relatively large bandwidth bus-like data transfer path. Having the trace memory physically contiguous with the processor allows for the processor in the protocol analyzer to have relatively efficient access to these large trace memories. Unfortunately, this requires that these devices be implemented using bus-interface connections on a standard PC board that are connected either as part of a desktop or tower personal computer configuration, or as part of a special purpose portable computer (a non-laptop device typically weighing more than 10 pounds and often referred to as a luggable computer).
In addition, most of the existing Fibre Channel protocol analyzers have utilized static random access memory (SRAM) to implement a deep trace buffer memory because of the speed and ease of memory management of such SRAM. SRAM has several disadvantages, however. First, it has a relatively high power consumption that can require larger, heavier and more expensive power supplies to support larger and deeper trace memories. Second, a trace buffer memory implemented in SRAM will be relatively larger than the same size trace buffer implemented in dynamic random access memory (DRAM). Unfortunately, some types of DRAM are more difficult to use in the context of a high speed trace buffer memory due to the potential conflict between the periodic refresh cycle of the DRAM and the need to write into the DRAM at a high bandwidth in order to capture traces from a high-speed communication interface, such as the Fibre Channel interface.
Another challenge faced by existing Fibre Channel protocol analyzers relates to the ability to search through a trace in the trace buffer memory looking for a particular data pattern. Protocol analyzers typically provide a search feature in which the trace buffer is scanned to look for a pattern defined by the user. In the prior art, this function is performed by the processor of the protocol analyzer, which for a PC-based analyzer would be the computer processor. To accomplish this, the computer processor must download the data from the trace buffer into the main memory of the computer processor, and a software routine is used to search for the specified data pattern in the main memory of the host processor. There are two disadvantages to this technique. First, it requires at least a partial download of the trace buffer into the main memory of the computer processor. This download can take a significant amount of time, depending upon the bandwidth of the connection between the trace buffer and the main memory of the computer processor. Second, the speed of the search is necessarily limited to the speed of the software algorithm as executed by the computer processor. Although it is known to incorporate test hardware circuitry into memory chips for the purpose of verifying the proper operation of those chips, as shown for example, in U.S. Pat. Nos. 5,247,648 and 5,406,566, such test circuitry has not been used in place of a software search routine to locate a particular data pattern that may or may not be present in a trace buffer.
Protocol analyzers have other potential design considerations that impact the manner in which trace buffers are preferably managed. One of the chief design considerations is the portability of the protocol analyzer. One approach to providing a highly flexible and extremely portable protocol analyzer is represented by the PassPort.TM. portable test chassis SCSI protocol analyzer offered by I-Tech Corp., the assignee of the present invention. Conventional SCSI protocol analyzers have been either desktop or tower PC-hosted devices that are not portable, or specially designed portable pieces of equipment that offer far less functionality and adaptability than a PC-hosted device. In contrast, the PassPort.TM. chassis contains a specialized motherboard in a relatively small case weighing less than 3 pounds that connects to a laptop PC via a parallel port cable and provides all of the capabilities of PC-hosted devices, without the need for specially designed portable pieces of test equipment.
Although portability is a desirable design objective for a protocol analyzer, this advantage has been achieved to date only by decoupling the processor from the trace buffer and imposing a relatively low bandwidth interface between the two. In the context of the requirements of managing a deep trace buffer memory for a high speed packet data communication interface, however, this approach would only aggravate the difficulties in managing the massive amounts of data that a Fibre Channel trace buffer, for example, must store and manage.
While existing Fibre Channel protocol analyzers are able to provide the deep trace buffers required for capturing and diagnosing packet data transfers on these high speed communication interfaces, it would be desirable to provide a Fibre Channel protocol analyzer that was more convenient and portable, and that was not necessarily constrained by the need to have the deep trace memory located contiguous with the host processor for the protocol analyzer. It would also be desirable to provide a deep trace buffer that could overcome the disadvantages of utilizing large memory transfers to the main memory of the host processor and software search algorithms to locate data patterns in the trace buffer.